Is there documentation on what constitutes a valid performer method? Some things I immediately wonder about:

• Can it assume an asyncio event loop is running? If so can it use it?
• How long can it take?
• Does it need to be reentrant?
• Might it be called concurrently?
• How can a daemon author say, in essence, "performer method X is blocked during the execution of performer method Y"?
• What is the (implicit) contract around errors and exceptions it should raise, if any?
• Are there restrictions on the return values?
• I can envision many commands where a get query needs arguments, especially for engineering/debug commands. It doesn't look like there is any provision for that.

Also I believe that Daemon._perform_get_wrapper is superfluous code as the performer will either be a function or a bound method of its class instance.

A quick example:

from typing import Callable

class Bar:
    def __init__(self, name:str):
        self.name = name
    
    def core_method(self, *args):
        print(f"Core method of {repr(self)} name={self.name} called with args: {args}")


class Foo:
    def __init__(self, method:Callable, b:str):
        self.anothers_method = method
        self.b = b
    
    def call_anothers(self, arg):
        self.anothers_method(arg, self.b)
        
    def core_method(self, *args):
        print(f"Core method of {repr(self)} {self.b} called with args: {args}")
        

x = Bar('external')
y = Foo(x.core_method, 'bval, foo instance')

y.call_anothers('some arg to call_anothers')
y.core_method('some arg to y core method')

and a deep dive is here https://docs.python.org/3/howto/descriptor.html

@baileyji The main thing I'm trying to accomplish with the wrapper method is to allow the implementation to define/provide a performer method that doesn't receive an Item instance as the first argument. If I used something like types.MethodType to replace the Item.perform_set reference, whatever I used there would receive 'self' (the mktl.Item instance) as the first argument.

I believe your example code effectively does the same thing as what's in the pull request; I store a reference to the externally provided method, regardless of whether it is a function or an instance method, and replace Item.perform_set with Item._perform_set_wrapper so the rest of the handling chain remains unaware.

I'll add language to the docstrings about the expected return values, I see that's missing. Thanks for the heads-up.

With respect to how the request is executed, I will add language to the docstrings for Item.perform_get() and Item.perform_set(), since it's relevant there as well-- and the documentation for the other methods should all be landing in the same place so it's only described once.

I can flesh out a similar structure for handling the raw request, in addition to this mechanism for overriding perform_get() and perform_set(); I'll look into that.

This pull request is starting to get a bit wordy with the families of methods to handle the various ways of adding and setting requests, but I think it's reasonably complete at this point.

@klanclos I see that from the code. The example code I gave and the link demonstrates why that is, if I'm reading correctly, superfluous.

Item appears to have a public .perform_set method that a subclass is expected to implement, an add_set_performer method that takes a callable (could be an already bound class instance method, could be a function, could be a lambda) and sets the class instance attribute _perform_set_external to that callable. It also replaces the class instances perform_set with the class instances self._perform_set_wrapper

self._perform_set_wrapper calls the callable stored at _perform_set_external

Replacing perform_set with method would not result in method receiving the class instance in its argument list.

class Bar:
    def __init__(self, name:str):
        self.name = name

    def core_method(self, *args):
        print(f"Core method of {repr(self)} name={self.name} called with args: {args}")

    def set_caller(self, arg):
        self.core_method=arg

x= Bar('bar')
print('Calling core method')
x.core_method()

print(f'Vars of {repr(x)}: {vars(x)}')

x.set_caller(lambda *args, **kwargs: print('lambda', args, kwargs, type(x).core_method(x, "a very perverse call")))
print(f'Vars of {repr(x)}: {vars(x)}')

print('Calling core method')
x.core_method()

gets

Calling core method
Core method of <__main__.Bar object at 0x11f2533d0> name=bar called with args: ()
Vars of <__main__.Bar object at 0x11f2533d0>: {'name': 'bar'}
Vars of <__main__.Bar object at 0x11f2533d0>: {'name': 'bar', 'core_method': <function <lambda> at 0x11f229940>}
Calling core method
Core method of <__main__.Bar object at 0x11f2533d0> name=bar called with args: ('a very perverse call',)
lambda () {} None

So strictly speaking the wrappers are just obfuscating.

I'd go further though.

I'd argue that in this instance a subclass should not override perform_set at all.

The base class should implement perform_set with all needed checks. and stub out def _perform_set(self): pass which the child class implements (or doesn't). The parent class is the able to enforce broader level contracts and hooks that a subclass author may not get right.

Also setting a performer can be assignment to _perform_set directly and the parent now has direct visibility on potential conflicts there wehn perform_set is called: it can see that both the instance is a subclass, it does/doesnot define _perform_set and that there is/is not an instance shadow of _perform_set in vars(instance).